These are the needed files for wayland mode to function properly. In general openbox and labwc format is compatible so this is not strictly needed but stuff like using foot instead of xterm and app by app variables needed for native wayland support vs xwayland it is better to have them in their own files.

This can be tested with:

docker run --rm -it --shm-size=1gb -p 3001:3001 -e PIXELFLUX_WAYLAND=true lsiodev/chromium bash

Zero copy AMD/Intel:

docker run --rm -it --shm-size=1gb -p 3001:3001 -e PIXELFLUX_WAYLAND=true --device /dev/dri:/dev/dri lsiodev/chromium bash

Zero copy Nvidia:

docker run --rm -it --shm-size=1gb -p 3001:3001 -e PIXELFLUX_WAYLAND=true --runtime nvidia --gpus all  lsiodev/chromium  bash

Labwc always shows the decorations on launch, down the line this can be disabled at the DE level but you can right click the bar and disable use system title bars.

Known wayland issues:

1. wl-copy and paste is slow and clipboard operations are sync right now (pending next release) so when refocusing into the tab you have to click a couple times before it responds to actions.
2. The cursor rendering is a placeholder for now as I cannot reliably get the cursor off of smithay
3. Resizing the window with a fullscreen high motion thing running in nvidia zero copy can make the chromium window go black, the session is alive and it can be closed and re-opened. This does not occur on intel or amd in my testing.
4. Changing video setting without firing a resize can cause clipping until another resize event.

This massively increases performance on systems with a GPU and sees a good uptick without one as well due to the nature of the new rendering pipelines, controlling the framebuffer, and being able to manage a dmabuf on an egl device. This translates to native performance as the screen is being rendered exactly like it would if it was plugged into a monitor and the encoding occurs on the card in a minimal memory copy manner. It also means we are not using an unknown path for 3d acceleration under Linux this works just like a real desktop despite it being a virtual framebuffer. So no hacks for zink support or patching of a software framebuffer.

For example here is an N97 running at 80 fps 1080p: